Creating Queues for Message Storage
Queues represent a layer of
communication indirection between services, allowing them to send and
receive messages independently of each other. A queue is a first-class
database object, internally implemented as a table that has some unique
behaviors.
Note
You can select values from any queue by using standard syntax, such as SELECT * FROM QueueName WITH (NOLOCK).
This has no effect on the data in the queue, nor does it imply a
message receive operation. It does, however, cause blocking on the
internal queue table, so you should always use the NOLOCK hint. Data Manipulation Language (DML) statements on queues are not permitted.
The following is the syntax for creating a queue:
CREATE QUEUE DatabaseName.SchemaName.QueueName
[ WITH
[ STATUS = { ON | OFF } [ , ] ]
[ RETENTION = { ON | OFF } [ , ] ]
[ ACTIVATION (
[ STATUS = { ON | OFF }, ]
PROCEDURE_NAME = SPName,
MAX_QUEUE_READERS = Number,
EXECUTE AS { SELF | 'UserName' | OWNER }
) ]
]
[ ON { filegroup | [ DEFAULT ] } ]
This syntax contains the following options:
STATUS— This option turns the queue on or off, meaning that it may or may not be used. (This capability is useful with ALTER QUEUE when a queue must be temporarily put offline.) It defaults to ON.
RETENTION— This option turns message retention on or off during active conversations that use the queue. It defaults to OFF.
You might need to turn this feature on at some point if you need to see
messages that have already been processed. The reason is that the
normal message receive operation implicitly deletes a message when the
transaction that surrounds it commits. When RETENTION is set to ON, the value in the status column for the queue is changed to 1 after a receive instead of a deletion. In addition, sent messages are copied to the sender’s queue (duplicated) and given a status value of 3, to fully audit the message flow in both directions.
ACTIVATION— This clause is used to specify the following options regarding the internally activated stored procedure (described earlier):
STATUS—This
option is used to turn activation on or off. (You may want to
temporarily turn off activation when updating a procedure.) It defaults
to ON.
PROCEDURE_NAME—This option specifies the name of the activated procedure.
MAX_QUEUE_READERS—
This option supplies an integer that indicates to Service Broker the
maximum number of instances of the activated procedure to create. This
setting hints at the fact that Service Broker uses multithreading to
instantiate additional queue readers when unread messages in the queue
build up faster than the existing instances can process them. This is a
great boon to developers because they no longer have to develop and
maintain the multithreaded code to perform this task. To do this,
Service Broker internally creates queue monitors that keep an eye on the
number of unread messages in the queue. Keep this number the same as
the number of processor cores you have in your system.
EXECUTE AS— This option specifies the name of the user under which the initiated procedure runs.
You need two queues for the application so far: one used by each service. The T-SQL in Listing 2 creates them.
Listing 2. T-SQL for Creating Queues and Their Activated Stored Procedures
USE XCatMgmt
GO
CREATE PROC Publication.CatalogChangeQueueReader
AS
GO
CREATE QUEUE Publication.CatalogChangeQueue
WITH
STATUS = ON,
ACTIVATION
(
STATUS = ON,
PROCEDURE_NAME = Publication.CatalogChangeQueueReader,
MAX_QUEUE_READERS = 10,
EXECUTE AS 'SSBTestUserName'
)
GO
USE AdventureWorks2008
GO
CREATE PROC Production.CatalogChangeAckQueueReader
AS
GO
CREATE QUEUE Production.CatalogChangeAckQueue
WITH
STATUS = ON,
ACTIVATION
(
STATUS = ON,
PROCEDURE_NAME = Production.CatalogChangeAckQueueReader,
MAX_QUEUE_READERS = 10,
EXECUTE AS 'SSBTestUserName'
)
|
The code in Listing 2 declares an empty stored procedure for each queue. You can fill this shell after you define the services.
